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(57) ABSTRACT 

The assembly and communication of multimedia informa- 
tion from a variety of modalities to remote users with 
improved control is provided for by the combined use of a 
browser enhancement module, such as a plug-in or ActiveX 
control, and a server. The server includes a data interface for 
acquiring the multimedia data and a storage unit for receiv- 
ing and storing the data. An assembly unit in the server 
gathers selected data to form an e-mail package in response 
to instructions from a remote user unit. The server further 
includes a processing unit to encode and compress the data 
prior to packaging and an e-mail server to send the package 
to the remote user unit or another designated user unit. 
Transfer instructions for the server may be provided by the 
remote user unit through a browser and the browser 
enhancement module. The browser enhancement module is 
therefore configured to request a file from the server, to 
decompress and decode received files and to transfer such 
files along with a user interface to a display associated with 
the remote user unit. The browser enhancement module is 
further adapted to send instructions to the server to assemble 
and to e-mail selected data from a file to another user unit. 
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MEDICAL NETWORK SYSTEM AND 
METHOD FOR TRANSFER OF 
INFORMATION 

NOTICE OF COPYRIGHT 

A portion of the disclosure of this patent document 
contains material which is subject to copyright protection. 
The copyright owner has no objection to the facsimile 
reproduction by anyone of the patent document or the patent 
disclosure, as it appears in the Patent and Trademark Office 
patent file or records, but otherwise reserves all copyright 
rights whatsoever. 

FIELD OF THE INVENTION 

The present invention relates generally to the transfer of 
multimedia information through the Internet, and more 
particularly to an integrated e-mail and server system for 
manipulating and communicating medical information. 

BACKGROUND 

In many fields (e.g., medicine, manufacturing, veterinary 
science, scientific research, etc.), it is often necessary to 
examine a subject and communicate the results of the 
examination to a remote place. Such information exchanges 
are especially desirable in the medical arena where it is often 
useful for medical practitioners to communicate medical 
information, such as patient test results, to other practitio- 
ners located in remote places. Telemedicine facilitates this 
exchange of information. 

Telemedicine is an emerging field that enables medical 
knowledge to be shared amongst a variety of users that need 
not be collocated. Interest in telemedicine has exploded in 
the 1990's with the development of medical devices for 
capturing data in digital electronic form and the establish- 
ment of high speed, high bandwidth telecommunication 
systems around the world. In particular, the use of the 
Internet in telemedicine allows a practitioner at one location 
to interpret medical test results and consult with another 
practitioner located elsewhere. Medical information transfer 
systems that employ the Internet allow for remote locations, 
such as third world countries that do not have an attending 
specialist, to access such medical expertise. Furthermore, 
emergency care may be provided where a practitioner is 
temporarily away, e.g., at home or on vacation. See, e.g., 
Thrall JH, Boland G., "Telemedicine in practice", Seminars 
in Nuclear Medicine 28(2): 145-57, April 1998. 

Medical information (e.g., as may be utilized by a tele- 
medicine system) may be derived from many different 
medical modalities. Such modalities may include sophisti- 
cated radiology equipment grouped as small matrix size and 
large matrix size instruments. Small matrix systems include 
equipment for magnetic resonance imaging (MRI), com- 
puted tomography (CT), ultrasonography (US), nuclear 
medicine (NM) and digital fluorography. Large matrix sys- 
tems include equipment for computer radiography (CR) and 
digitized radiography (DR). Other data image acquisition 
equipment may be used for radiofluoroscopy, angiography, 
such as x-ray angiography and heart scanning. Still other 
equipment of great usefulness in acquiring medical infor- 
mation includes secondary capture devices for video, 
endoscopy, microscopy, and photography, such as digital 
cameras, scanners, electrocardiogram (ECG) machines, and 
the like. 

The resulting medical information may take numerous 
forms, including text, images and video, or variations 
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thereof, such as image overlay data, measurements, 
coordinates, etc. Information may also be in the form of 
lime-dependent data including sound, such as audio 
dictation, and waveform data. The data may be static rep- 
5 resentations of timedependent forms, such as curves. Thus, 
it is advantageous for telemedicine systems that may need to 
transfer the data and/or information to be flexible, so as to 
accommodate this variety of information/data from multiple 
modalities. 

10 Unfortunately, this type of flexibility is not exhibited in 
current systems. For example, some current medical infor- 
mation transfer systems have integrated medical modalities 
to not only generate data but also to capture data signals, to 
store the data and to transmit the data over the Internet. 

15 Typically, in such systems the modality has an integrated 
Web server, storage database and Web pages as physical 
parts of the modality system. A remote Web browser is 
allowed to request data from the modality through the 
Internet (e.g., via the World Wide Web) and the Web server 

20 in the modality is allowed to respond accordingly. One such 
system, which has restricted applicability to ultrasound 
machines, is described in U.S. Pat. No. 5,715,823. 

One drawback of such systems is that individual Web 
servers are required for each medical modality unit, making 

25 it a costly endeavor to share data among a number of 
practitioners. Furthermore, each server is limited in use to 
only the attached type of medical modality. 

Other systems for transferring medical files are adapted to 

3Q accept data from a variety of modalities, but require an 
interface to convert data into transferable signals. One such 
system described in WO 98/24358 converts system binary 
file data from a modality to a compatible file of keystroke 
codes using an' adapter. The codes are transferred to a 

35 computer, which converts the codes to American Standard 
Code for Information Interchange ("ASCII") characters for 
transmission over the Internet to a host computer. This 
multiple file conversion process is an unnecessary burden, 
however, as current Internet technology does not require that 

40 information be converted into ASCII format. Presently, the 
Internet accepts binary Extended Binary Coded Decimal 
Interchange Code ("EBCDIC) and ASCII codes. Thus, an 
ASCII adapter is now an unnecessary extra device for 
transmitting medical data. 

45 In addition to simply receiving the medical information, 
it is often important that a practitioner receive the informa- 
tion in a timely manner, especially where a quick diagnosis 
needs to be rendered for patient care. Thus, it is advanta- 
geous for telemedicine systems to rapidly transfer medical 

50 data. As noted, some current telemedicine systems rely on 
the Internet (i.e., as accessed through its graphically- 
oriented user interface, the W 7 orld Wide Web) to transfer 
information. However, current Web-based transfer systems 
often suffer from long delays in downloading Web pages 

55 having complex data, such as large images. This presents a 
particular problem for the rapid sharing of medical infor- 
mation as a typical MRI study, for example, may have over 
100 images, each of which may be 300 to 500 Kb in size, 
loading to a study of 50 to 80 Mb total. 

60 These transfer times may be enhanced by compression of 
the data prior to transmission over the Internet. Traditional 
compression schemes (e.g., JPEG, GIF and bitmap 
schemes), however, tend to operate at low efficiencies. Such 
low compression efficiency may only provide for transfer of 

65 simple data before significant resolution losses and/or the 
truncation of data segments is/are experienced. With the use 
of high efficiency compression methodologies, such as 
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wavelet compression techniques, transfer times can be 
reduced twenty fold. Unfortunately, however, the use of 
such high compression efficiency schemes is not prevalent 
among current telemedicine systems. 

Another approach to solving the dilemma of lengthy 
transfer times is with the use of electronic mail ("e-mail"). 
E-mail provides a user with apparently instant transfer 
times, because information is sent as a package in advance. 
Using e-mail, studies may be "pushed" to the user so that the 
files are already available at the user's computer when the 
user is ready to view the data. By contrast, when a user 
requests a Web page through a browser, each page must be 
separately downloaded. 

Some current e-mail technologies allow for the point-to- 
point transfer of a variety of data from different modalities. 
However, these systems do not operate with a central storage 
system. Without a server database, the operations are lim- 
ited. For example, one may not retrieve information about 
how multiple images relate to one another. Such relationship 
information is essential for studying data from certain 
modalities, such as radiology images, and is required for 
compliance with some medical industry standards, e.g., the 
multi-specialty DICOM Standards (as originally published 
by an ACR-NEMA committee sponsored by the American 
College of Radiology and the National Electrical Manufac- 
turers Association as Digital Imaging and Communications 
in Medicine (DICOM), NEMA Publications PS 
3.1-PS3.12., by The National Electrical Manufacturers 
Association, Rosslyn, Va., 1992, 1993, 1994, 1995). 

The DICOM Standards define the form and flow of 
electronic messages that convey images and related infor- 
mation between computers. Therefore, it is desirable for 
medical information transfer systems to acquire and transmit 
complex data, such as radiology images, in a manner that 
complies with DICOM standards. See, e.g., Bidgood, et al., 
"Understanding and Using DICOM, the Data Interchange 
Standard for Biomedical Imaging/' J. Am. Med. Informatics 
Assoc., 4:3, 199-212, May-June, 1997. As indicated, 
however, some systems do not meet this requirement. 

Other medical e-mail systems are limited to purely textual 
data forms. An example of a medical information transfer 
system' of this type is described in WO 98/16893. This 
system allows a service request to be sent by one operator 
through a client system to another operator at a sponsor 
system. The request may be for some action to be performed 
by the operator at the sponsor system, such as to perform a 
test, or to provide authorization therefor, and the like. 
Although perhaps useful, these textual systems are not 
designed to transfer complex data, such as images and 
multimedia output, generated by many medical modalities. 

Thus, in light of the shortcomings of the various currently 
available systems, there is still a need for medical transfer 
systems that allow for transfer of complex data from a 
variety. of modalities over e-mail and web browser systems. 

SUMMARY OF THE INVENTION 

In one embp^imenUaimedical information transfer server 
is provided mt^K^^S^ adapted to store multimedia 
medical data (e.g., parameter and/or clinical data) and 
includes a data interface for acquiring the medical data; a 
storage unit coupled to the data interface and configured to 
receive and store the medical data; and a user interface (e.g., 
a Web page) for viewing the medical data. In some cases, 
individual storage subunits may be used for storage of the 
parameter and clinical data, respectively. An assembly unit 
may be coupled to the user interface, the storage unit and/or 
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the data interface. The assembly unit may be used to gather 
selected portions of the stored medical data (and/or new 
data) to form an e-mail package. In some cases, such actions 
may be undertaken in response to instructions from a remote 

5 user unit. Often, the server will include a processing unit, 
which may be coupled to the assembly unit or the data 
interface, configured to encode, compress and/or encrypt the 
medical data (e.g., prior to the data being assembled into an 
e-mail package, or even prior to being stored). In other 

10 configurations, separate processing units may be used for 
some or all of these functions. In any event, various com- 
pression schemes may be employed, such as progressive 
compression schemes, wavelet, motion wavelet, MPEG 
and/or motion JPEG schemes, and the like. In the progres- 

15 sive schemes, any suitable compression algorithm may be 
used in a looping fashion to compress the data to a desired 
or acceptable size. An e-mail server configured to send the 
user interface and the e-mail package to the remote user unit 
and/or another user unit may also be included. The multi- 

2Q media medical data stored by the server may be text, image, 
overlay, 3-D volume, waveform, curve, video or sound data, 
or any combination thereof. 

The server may further include a 3-D volumetric render- 
ing element and/or a 3-D surface rendering element for 

25 converting 2-D images into 3-D images. Window and/or 
level controls may be included for establishing window 
and/or level default values. In some cases, an automatic 
e-mail control may be included to direct the e-mail server to 
automatically send any new medical data to the remote user 

3 q unit at prescribed intervals. 

Another embodiment provides a medical information 
transfer unit that includes a display for viewing a medical 
file on a user interface having at least one manipulation 
element for view control of the medical file, and a browser 

35 for communicating with a server having stored therein a 
plurality of medical files containing multimedia medical 
data. The browser includes a browser enhancement module 
configured to request a medical file from the server; 
decompress, decode and/or decrypt the medical file (if 

40 necessary); transfer the medical file to the display; and/or 
send instructions to the server to assemble and to e-mail 
selected medical data from the medical file (which may 
include clinical data, parameter data, series data, annotation 
data, observation data, 3-D volume data, and/or combina- 

45 tions thereof) to a remote user unit that is separate from the 
transfer unit. 

The browser enhancement module may be a plug-in or an 
ActiveX control, where appropriate. Further, it may be 
configured to instruct the server to assemble selected data 
50 with new data to form a package and to e-mail the package 
to the remote user unit. This new data may be originally 
acquired by the transfer unit through an associated modality 
interface. 

Still other embodiments may provide a computer readable 
55 medium having stored therein a plurality of sequences of 
instructions, which when executed by a processor, cause the 
processor to perform certain steps (e.g., through the use of 
a browser or otherwise). Among these steps may be included 
the steps of requesting from a server a medical file on a user 
60 interface having at least one manipulation element for view 
control of the medical file, the server having stored therein 
medical files containing multimedia medical data; 
decompressing, decoding and/or decrypting the medical file; 
transferring the medical file to a display; and/or e-mailing 
65 instructions to the server to assemble and send selected 
medical data from the medical file from the server to a 
remote user unit which is separate from the processor. The 
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medical data may be in the form of text, image, overlay, 3-D FIG. 1 illustrates one embodiment of a medical informa- 

volurae, waveform, curve, video or sound data, or any tion transfer system configured in accordance with the 

combination thereof. Of course, other embodiments may teachings presented herein 

provide only the instructions themselves or the instructions FIGS 2A _ 2D are Hock ^ ^ of various embodi . 

as earned m a data signal by a earner wave 5 ments of t ^ d in accordinC6 ^ the teach . 

According to still further emboaments, multimedia mfor- ^ (ed herej wherejn n& 2A shQWS a 

mation from a vanety of modahties may be assembled and „ r u * j * • j CT p in 

. j . 17 , .... 17 j + i l »i_ where new data is compressed prior to storage, MG. 2B 

communicated to remote users with improved control by the . * - * * j * 

combined use of a browser enhancement module, such as a shows a m l p w ^ " ew data 15 stor ^ d wthau ' P nor 

plug-in or ActiveX control, and a server. Aremote user unit 1(1 com P r e s sion, FIG. 2C shows a server where new data is 

that includes the browser enhancement module may access 10 assembled and then stored and FIG. 2D shows a server 

and manipulate data stored in the server by sending instruc- where new data 15 assembled and then processed as well as 

tions thereto. In some cases, communication is achieved, at stored. 

least in-part, through an e-mail system integrated with the FIG. 3 is a block diagram of one embodiment of a user 

server, where the server assembles and sends the e-mail unit configured in accordance with the teachings presented 

package. By this design, a user may transfer information 15 below. 

stored on the user's computer, but is not Jimited4o~e-mail-n FIG. 4 illustrates one embodiment of a user interface with 

transjeis^ the user mav/^ manipulatiori elements configured in acc0 rdance with the 

access and conj^^ teachings presented herein. 

ent-sources-^ sucrr as ^^^fBL^t^^tnicC the'- server to / to r 

retrieve useful data~from~oiher rBmofe hosts, iV th^reby pro- 20 DETAILED DESCRIPTION 
viding-the-user.or_, anothe r rece iying^parjy_ withja compre- 
hensive package of information. "* The Medical Network System and Method for Transfer of 
The benefits of information storage on the server are Information described below is confi gured to provide_ ajlch- 



direct in that the type of information available to a user is variety of image manipuhtiork-viewing.an^ m^pi^ lools 
flexible and may be in compliance with the DICOM Stan- 25 for_review-of-Mormatior^and transferj>f t^nl^aMCtQ. 
dards. In one embodiment, portions of data files are related remote users. The ^svstem utilizes browser and/or e-mail 



dards. In one embodiment, portions of data files are related remote ^se^^Jhe ^! 

to other portions of files stored on the server. The server may p1fi'l?a15ctTfient v units, ^uch as may be-embodied~kra~plug-Tn 

also store associated information such as specific parameters vfor— Netscape-brand browser interfaces (e.g., Netscape 

used by a modality in deriving medical data, notes and Navigator) or MIME interfaces, or an ActiveX control for a 

observations made by a practitioner, as well as patient 30 Microsoft-brand browser interfae (e.g., Internet Explorer), 

histories. to provide this rich application environmenTTjy incorporat- 

Other embodiments further provide for sophisticated m g advanced functionality into a down-loadable browser 

manipulation of data (e.g., medical information). Requested enhancement unit, a user need only have available basic, 

data may be received by a user unit through a user interface, computer equipment, such as an off-the-shelf personal com- 

such as a Web page, from a server. The user interface may 35 puter (PC) equipped with an Internet browser. Furthermore, 

provide a wide selection of view controls for optionally the integrated functionality provided by the present system 

manipulating the manner in which data is displayed. Some allows correspondents anywhere on the Internet to instantly 

or all of these controls may be included in a browser nave me same tool kit. 

enhancement module, which may make up a portion of the The data that is transferred by the operator of a server 

user interface (with the remaining portion of the user inter- 40 configured in accordance with the present teachings may 

face being stored at the server). The server may additionally take numerous forms. Some common formats include text, 

have controls such as 3-D image rendering device to allow images, video, sound, such as audio dictation, waveform, 

for further viewing enhancements. curves, and/or combinations or variations thereof. 

In still a further embodiment, a server and/or a browser Moreover, although the data may pertain to the examination 

enhancement module may be configured to receive complex 45 of a subject in any number of fields, such as manufacturing, 

data from a variety of sources. To avoid truncation during veterinary science, scientific research, etc., the data is pref- 

transmission of large data files, such as radiology files with erably medically related to a subject's physical condition, 

numerous images, high level compression schemes, e.g. Medical data of this sort may be grouped into various types, 

wavelet compression schemes, may be employed to reduce Clinical data is information acquired by a medical modality 

the size of any transferred data files. In some cases, the 50 during the examination of a patient and relates to the 

enhancement module may be configured to acquire and/or patient's physical health. Examples of clinical data may 

encode new medical data directly from a medical modality. include radiology images, camera photographs, sound 

The enhancement module may pass such new medical data recordings, and the like. Parameter data is another type of 

to the server along with specific instructions regarding how data representing criteria surrounding the acquisition of 

the server is to handle the data. For example, the enhance- 55 clinical data. Parameter data includes the settings of the 

ment module may instruct the server to assemble the new medical modality acquiring the clinical data, relationships of 

data with data stored on the server and send the resulting multiple sets of data such as overlay data, timing of the data 

package to another remote user. In addition, the enhance- acquisition, measurements, coordinates, and the like. The 

ment module may be configured to direct the operation of a parameter data includes some of the information required by 

remote medical modality in deriving medical data. <so the DICOM Standards for stored and transferred medical 

Other features and advantages of these and other embodi- file s- Other medical data may include 3-D volume data; 

ments are discussed in detail below. senes data for a11 clinical data in a medical series, e.g., 

coronal slices vs. axial slices in a CT exam or echoes as Tl 

BRIEF DESCRIPTION OF THE DRAWINGS slices vs . ^ s]ices in an MRI exam; anllola ti on data for 

The present invention is illustrated by way of example, 65 notes made by a practitioner, usually relating to the clinical 

and not limitation, in the figures of the accompanying data; and background data such as patient history and/or 

drawings in which: physical examination information. 
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FIG. 1 illustrates an exemplary information transfer sys- the data interface 22 may be an Ethernet port). However, 

tern 10 configured in accordance with one embodiment of other communication schemes are suitable for transfer of 

the present invention. A modality 12 is coupled to a server data from modality 12 to server 20, such as serial interfaces, 

20 through a dicomizer 14. A second modality 16 is option- parallel interfaces, RS422 and/or RS432 interfaces, 

ally coupled to a user unit 50, which unit may communicate s Livewire interfaces, IEEE-1394 serial busses, Appletalk 

with the server 20. The user unit 50 may have components busscSj ^ busses and/or networkS) token ring and/or 

to optionally view, manipulate store and/or print data con- other local area netW orks, universal serial buses, PCI buses 

figured by modality 16 or modality 12. The user unit may and wirelcss ( infrarcd) and thc ^ 

transfer such data to the server 20 and/or send the informa- . . 

tion to another user 80 through the server 20. The other user Now re±ernrj g in m °re detail to the server components 

unit 80 may also communicate with the server 20. It should 10 shown in F } G - 2A > a processing unit 24 is coupled in 

be noted that the scope of the present invention anticipates communication with data interface 22. Processing unit 24 

any number of modalities, user units and servers configured provides a mechanism to allow for the compression of data 

in accordance herewith and arranged in various fashions. by a compression component 26 prior to storage. For 

The modalities 12 and 16 may be any type of device that example, processing unit 24 may be a general-purpose 

generates data or data signals related to the examination of 15 processor that transfers data to and from compression com- 

a subject. The subject is preferably a human being or an ponent 26. Alternatively, processing unit 24 may be a 

animal, but may also be an inanimate object that is being processor configured to execute instructions defined by 

inspected. The modality may perform the direct examination compression component 26 (e.g., where compression com- 

of the subject, where the modality includes a detection ponent 26 is a computer program). The compression of data 

component. Alternatively, the modality may create data or 20 conserves storage space and/or provides for the speedy 

signals from a user's input, where the modality has an input transmission of data to the user unit, whereat the browser 

component such as a keyboard, mouse, microphone, etc. enhancement module to be described below may be used to 

Typically, the modality is a med^al^a^ice^Medical *0 decompress the data, 

modalities used in radiology inchi^ta^/awt^n^^ ^ for one embodiment, the processing unit 24 may 

ment for ma^etic resonance j imaging^(MR^ r c«mp^ 25 usc variou& convenicnt algorithms that allow data files to 

tomography (CT), ultrasound (US), nuclear medicine (NM) , . , . , , 4 . , , Tt_ i *u . j 

and digitized radiography (DR , computer radiography (CR f h nok in t ° rd K er l ° ^ , data * ^ al S° f r ^ ms te * d 

and digital fluoro^aphy Other modalities include photo- t0 °P erat< ; b ? r A e P lac fg repeating patterns of data with 

graphic devices such as high resolution digital cameras; smaller tokens. A header may be added to the data file as it 

sound capture interfaces such as verbal dictation interfaces, 30 13 compressed for containing information necessary in the 

Sound Blaster™ interfaces, and the like; video capture reconstruction of the file when it is decompressed. In 

interfaces such as Snappy® brand paralleLoort videoxapture addition, a header may be included which retains informa- 

devices; flatbed scanners_and especiallyl^n^mfiantr^ tion on ^ wa V the data was attaincd and how onc data 

fJcquisitiom~dewces^^ e -g-> an 1IDa g e > relates to another represen- 

t^adalifies^ye^for-angiography, radiography, endoscopy, 35 tation ™ ^ same set of data ' C -S- " series ima£C 39 and 

microscopy, physical exams and waveform devices to col- echo 2. 

lect EEG and/or ECG data, such as from Hewlett Packard Generally, compression formats are either high efficiency 
Corporation of Palo Alto, Calif, and American Medical or low efficiency and either lossless or lossy. Lossy corn- 
Devices Corporation of Lowell, Mass, In addition, the pression schemes are characterized by components of an 
present invention anticipates other modalities and all of the 40 original image being absent from a reconstructed image after 
aforementioned modalities are by way of example, and are a compression-decompression cycle. Lossless schemes do 
not intended to limit the choices that are or may become not drop any information. Compression levels for any 
available in the art. scheme may be chosen to be in compliance with the Food 
As shown in FIG. 1, the dicomizer 14 receives data from anci Dra g Administration (FDA) requirements for a particu- 
modality 12 and conveys the data to server 20 where it may 45 l ar application, e.g., diagnostics or referral quality, 
be processed, stored and/or sent to user units. Dicomizer 14 Low compression schemes (i.e., those that do not provide 
is an optional component to the information transfer system significant compression ratios) that may be used include 
that converts the raw data into DICOM compliant data. joint photographic experts group (JPEG) compression 
Dicomizer 14 may be a stand-alone device, or alternatively, schemes that use Fourier analysis-based methods, such as 
may be an integral part of a computer system for controlling 50 the discrete cosine transform, to compress data; graphics 
Der ations of th e modality. interchange format (GIF) compression schemes, which use 
^trans fer system lSSi^aS^ algorithms; bitmapped image compression schemes 
lS^^^£istaBeSil3?ie and tagged image file format (TIFF) compression schemes. 
^fn1et^ifefn^nlranelT~o^an7 Alternatively, high efficiency compression schemes, such as 
f^mousiy in FIGS. 2A-2D,server20has 55 wavelet, motion wavelet, Motion Picture Experts Group 
^onT^SBSft^for handling data in various ways. These com- (MPEG) and/or motion JPEG schemes may be employed, 
ponents include a data interface (DI) 22 to receive newly Use of such high efficienciey schemes may be preferred 
acquired data, a processing unit 24 for manipulating the where storage space and/or transmission bandwidth is lim- 
data, a storage unit 30 for retaining (i.e., storing) the data, an ited. For example, wavelet compression schemes may be 20 
assembly unit 32 for gathering together information and an so iimts more efficient than JPEG compression schemes, pro- 
e-mail server 36 for sending the information so gathered. viding for a more detailed representation of the data at the 
Upon review of this specification, it will be appreciated by same bit budget. 

those skilled in the art that the components of server 20 may In one embodiment, a progressive compression scheme is 

be connected in other ways in addition to those described used prior to storage of data, wherein data is incrementally 

and shown in FIGS. 2A-2D. 65 compressed to varying sizes. An advantage of progressive 

In one embodiment, modality 12 may communicate with compression is that where the data is prepared for e-m ailing, 

the data interface 22 through an Ethernet connection (i.e., the server may pull the largest size of data that is capable of 
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being compiled into a package. In this manner, truncation by An advantage of this adjustable compression scheme is 

intermediate mail hosts causing the loss of data segments is that truncation of data may be avoided. With prior compres- 

avoided. Moreover, the largest acceptable data size also sion schemes, an e-mail package that is larger than the 

provides the optimal resolution for the data when it is required size typically has sections of the data removed from 

viewed. , , — 5 ^ e-mailed package. Thus, the recipient only receives a 

^Sejwr^OT^^^ portion of the requested information. Furthermore, adjust- 

storfnMffj ^ a bie compression allows a variety of modalities to be 

^mro'^f^^ a file. Such files may transferred by e-mail because usually medical files from 

v -conta^ of data from a variety different modalities have much more data than the accept- 

^^^^^o^m^T subject or group of 10 abk size for e _ maiL For cxample , a typical computed 

s ^PJ32§i— • i tomography file is about 50 megabytes in size and a com- 

An assembly unit 32 is coupled to the storage unit 30 for ted radiography filc ^ about 10 megabytes in size. Unless 

gathering selected medical data and the appropriate user ^ relativel large files are compressed to 2 to 3 

interface pages to form an e-mail package in response to megabytes ^me of ^ information is truncated when sent 

instructions from a remote user unit The assembly unit 30 ^ ^ h e . mai] ^ in f ormation ^ not transferred 

pulls appropriate medical data from the storage unit 30 and ^ ^ reci ient receives only a portion of me flle 

compiles the data. In one embodiment, the assembly unit 30 „ . . ^ A A 

only groups the information but does not arrange the infor- Pressing unit 24 also has an encoding component 28. 

mation in the order in which it will be viewed by a user unit. ™ e component 28 converts the data into codes 

Instead, software, e.g., a browser enhancement module, at "cep'*"* l ° e " mal1 ' " sua ( ^> data is encoded for Inter- 

the user unit rearranges the information for viewing. 20 » et transf6r ^ ^ A/c k 10 

jl ■ 4 _r nmi-i u -tt T i . ., , that is recognized as a MIME binary compliant object. The 

A user interface (UI) 34, such as a Web page, is prov.ded kc »^ lication recogn 4 s the MIME encoding 

to assembly unit 32 for collection mto the e-mail and enhaneement module t0 decode the 

package. The user interface 34 may be a complete or attachment 

incomplete page. Preferably the interface is an incomplete 9 , 

interface and the remaining portion of the user interface is In some cases ^ Processing unit 24 may include an 

provided by a browser enhancement module in the user unit. encryption component to encrypt the data prior to sending it 

The interface 34 may be a group of interface pages that are & X0U Z h e " mai }- A variet y of encryption schemes may be 

connected by hypertext or other links. used such 45 P ubhc ke y encryption or private key encryp- 

The Web page(s) that make up UI 34 may be organized in 30 f 0 '*™ ** y encr yP tion > server may keep a 
tree structure, wherein information is arranged hierarchi- ***bw of pubhc keys in a key registry (e.g.,m storage unit 
cally from general to more specific data. However, the pages 30 ) ' ™ e encochn S aad/or encrypting components may be 
may also be arranged in a linear structure, wherein one page stand-alone components ,or software components (separate 
leads to the next page, or the pages may be arranged in a or combined) executed by the processing unit 24. 
random structure. Tree structured Web pages may be used, 35 Server 20 also includes an e-mail server 36 coupled to the 
for example, where an operator is provided with a list of processing unit 24 and configured to send the e-mail pack- 
patients' studies. The operator may select from various age having the data and at least a partial user interface to user 
instances of treatment or separate types of data, e.g., labo- units 50 and 80 - The e-mail server breaks messages into 
ratory results, radiology with reports or pathologies. Appro- packets, e.g., as according to the TCP protocol, and delivers 
priate related data from an external database may be dis- 40 the packets to user units 50, 80, such as with the IP protocol, 
played as part of the selected data. In another variation of the server 20, as shown in FIG. 2B, 

In the exemplary arrangement shown in FIG. 2A, the the data interface 22 is not coupled to the processing unit 24. 

assembly unit 32 is further coupled to processing unit 24 to Instead the data interface 22 is coupled to a storage unit 30. 

allow for preparation of the e-mail package for sending. In tnis configuration, the data is not compressed prior to 

Assembling of e-mail packages allows for shorter times for 45 storage, but is compressed after storage in preparation for 

processing, e.g., compressing and encrypting, the e-mail for transmission (e.g., by e-mail). 

sending because the entire package is processed as a whole FIGS. 2C and 2D ^depict further embodiments of the 

rather than as individual items, which would need to be server 20 and its components, where the data interface 22 is 

attached as various components to the e-mail package. coupled to assembly unit 32. In these configurations, data 

To prepare the package for e-mailing, the compression 50 received from the data interface 22 is first assembled into an 

component 26 of the processing unit 24 may further com- e-mail package. The packaged information may optionally 

press the package into a size that is optimal for e-mailing. As be placed into storage and then pushed into the processing 

indicated above, one method of achieving the proper com- unit 24 from the storage unit 30 as illustrated in FIG. 2C. 

pressed data size for e-mail is by adjustable or progressive Alternatively, FIG. 2D shows that the package may be 

compression. In such schemes, processing unit 24 may 55 directly processed for sending by the processing unit 24 

compress the assembled medical data to a default ratio, such and/or stored in storage unit 30. From the server, the user 

as 2: 1 . The processing unit may then measures the size of the unit receives the requested information, 

compressed medical data package and compare it to the size The user unit 50 and server 20 may be in communication 

that is required by e-mail. The size required by e-mail is that through a variety of connections. FIG. 3 shows one example 

size that allows for the data to be sent without leaving 60 of a user unit 50 with a server connection 56. Server 

portions of the data behind. Typical requirements for e-mail connection 56 may be a telephone line, local area network 

are about 2 to 3 megabytes. If the current data size is greater , (LAN) or wide area network (WAN)- The communication 

than the required size, processing unit 24 compresses the link may be also made by a serial line Internet protocol 

data a second time. The package size is again measured and (SLIP), point-to-point protocol (PPP), an online service, an 

compared to the required size and this procedure may be 65 XDSL link, a- satellite or other wireless link, a cable modem, 

repeated until the data size becomes equal to or less than the an ISDN line, or another communication link. ISDN lines 

required size. are useful because ISDN is a digital technology using copper 
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cable telephone wires so that there is no need to convert baseline features. Typical browser enhancement modules 

information from digital to analog form prior to transmis- provide support for new data types and add operations to the 

s ion. Typically, se rver_connection 56 is an HTTP conne ction. browser. Browser enhancement module 54 is preferably 

""User unit 5(Hncludes^ platform 51, e.g.Vape^ojiaf) cither a full page type or embedded and visible type, but any 

mput&r^^ S format is possible. 



Browser enhancement module 54 is configured to instruct 
server 20 as to how to handle particular medical data and 



Macintosh ™ f oj^QpeTof-^wide variety of rufdware platforms 
that n&l^^iMx^ operating-systemT The user unit 50 

further includes~a~display 58, which is coupled to the files. Depending on the particular application of the transfer 
platform 51 through display controller 59. Display 58 may system, the server 20 may handle the data in many ways, 

be any one of a number of conventional display devices such 10 Instruction component 60 receives requests from the user 
as a liquid crystal display or a video display. For sharp colors and directs the server 20 accordingly, 
and grayscale, display 58 is preferably an SVGA monitor, [ n some cases asjfefiictcdjn FIG. 3, user unit 50 may 
with a resolution of 26 dpi or better, and an active area of at generate new data and browser52 may bTSs^to transtefn 
least 17 inches, controlled using a true color video card. The rthis-new-daU-to^he^servcr^O. In snch-cases/Wunfction^ 

DICOM Standards have also established specific display 15 \omponent60-instnicts-the-serveras to what to do with the 
preferences and the use of DICOM compliant video display new data. The new data is information that is not yet stored 
devices is contemplated as part of the present invention. in the server 20 and may include an alteration to stored data 
User unit 50 makes use of browser 52, i.e. Web browser in the server 20. Furthermore, the new data may also be data 
software, for communicating with the server 20. The that had been newly acquired from a medical modality (e.g., 

browser 52 issues a request, e.g., an HTTP request, for a 20 modality 16 in FIG. 1) in communication with the user unit 
particular user interface, e.g., a Web page. The browser 52 50 or data that has been dragged from the user unit, e.g., 
is also used in viewing the user interface. Commercially retrieval from a hard drive, desktop, or an input interface 
available browsers suited for use in accordance with the such as a key board, etc. The dragged data may be dropped 
present invention include Netscape Navigator™ from into a file for transferring to the server 20. 

Netscape Corporation located in Mountain View, Calif.; 25 In order to transfer the new data to the server 20, the 
Internet Explorer™ from Microsoft Corporation located in encoding component 62 of browser enhancement module 54 
Redmond, Wash.; and Lotus Notes™ from Lotus Develop- codes the data following compression thereof by compress- 

ment Corporation loc ated in C ambridge.„Mass: ~~ m 5 component 64. The encoding and compressing schemes 

^Usex^unit. 50 further indu&s^Jai ^ may be similar to those employed by the server 20 prior to 

^mE^ggl!^ a data transfer and may employ one or more processors) of 

50.JThe jrowser-^Bhancement module 54 perfonris^the platform 51. 

necessary tasks to make the data readable or transferable. Instruction component 60 may instruct the server 20 to 

Because the module is preferably an integral part of the store the new data. In such cases, when the server 20 

browser, it provides superior capabilities in interacting with 35 receives the new data7 t|^aja J i ^o^.o^^by-processing unit 
the browser and Web, as compared to a helper application, 24 and placed intothe servers storage unir30rTlie-serv^i20 
which runs separately from the browser in its own applica- may also optionally encode the new data in a standard 
tion space. This also provides a convenient way to deliver a DICOM format prior to such storage, 
completed package of integrated tools to the user's desktop. Instruction component 60 may further (or alternatively) 

Enhancement module 54 may be configured for a par- 40 instruct the server to e-mail the new data to a second user 
ticular browser, such as a plug-in for the Netscape unit 80. Although FIG. 1 depicts only two user units, it 
Navigator, or an ActiveX control for Microsoft's Internet should be appreciated that any number of user units may 
Explorer or Multipurpose Internet Mail Extensions (MIME) receive data from the server 20. The operator of user unit 50 
interfaces. Because browser enhancement modules are plat- may provide the names or addresses of those user units to 

form specific, type-specific modules must usually be down- 45 receive the data and instruction component 60 may transfer 
loaded according to a particular unit's operating system and this list to the server 20 with the forwarding instructions. In 
processor platform. However, in one embodiment a single the alternative, a predefined list of destination user units may 
enhancement module 54 includes programs for several types be retained in a database either at the user unit 50 or server 
of browsers. A detector in the enhancement module deter- 20. Optionally, this destination database is automatically 

mines the type of browser on which the component is being 50 updated between related servers. 

run and then configures itself to be the appropriate software. Instruction component 60 may be further configured to 

In this manner the browser enhancement module 54 may be instruct server 20 to merge specific other data with the new 
run consistently across all platforms. Furthermore, the data to form an e-mail package, e.g., for forwarding to a 
browser enhancement module 54 may communicate with the second user unit 80. The specific other data may be data 

server 20 and may automatically update itself. In this 55 already stored in storage unit 30 of server 20, data stored in 
manner, all browser enhancement modules may be consis- a remote information system e.g., a hospital information 
tently revised to be of the latest version. Thus, an advantage system (HIS) or radiology information system (RIS), data 
of the present data transfer system over those of the past is stored in a third party telemedicine package, or the like, 
that the necessity of using a myriad of different software Alternatively, the instruction component 60 may instruct 

tools or workstations for each type of data generated by 60 serV er 20 to send only specific other data without any newly 
various modalities is avoided. All of the necessary compo- added data. 

nents are embedded in the browser enhancement module 54 Enhancement module 54 further includes a request com- 

and the server 20. ponent 66 configured to solicit data or other information 

Browser enhancement module 54 adds functionality and from the server 20. When such data is received, the data 

interactivity to a user interface by integrating code, usually 65 must be processed in order for it to be viewed. Thus, 
in a seamless manner. The code module appears as extended decompression component 68 is included to reconstruct the 
capabilities of the user interface, undistinguishable from its original file so that it may be used by user unit 50. Decom- 
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pression component 68 may examine the e-mail package as 
well as any tokens in the data file to accomplish this result. 
In addition, a decode component 70 may convert the e-mail 
into a readable form. If the data was encrypted by the server, 
then the enhancement module 54 must also decrypt the 
message. 

Enhancement module 54 may also include a user interface 

72 with one or more interface pages 73, e.g., Web pages, 
having various manipulation elements 74 for dictating how 
the data is viewed within the user interface. In one 
embodiment, the enhancement module 54 has a portion of a 
user interface 72 with the manipulation elements 74 and the 
server 20 has the remaining portion of the user interface. The 
server 20 transfers its portion of the user interface to the user 
unit 50 and the enhancement module 54 merges these 
portions together to form a complete user interface. 

Manipulation elements 74 are used by the operator to alter 
the display of information or data, typically by selecting the 
controls as they appear on the user interface with a mouse or 
other user control device. FIG. 4 illustrates one completed 
user interface page 73 with a plurality of manipulation 
elements 74. The enhancement module 54 may provide for 
any desired number of manipulation elements 74, typically 
being from 1 to 50, more typically from 4 to 25 and usually 
at least four elements. It should be appreciated that UI page 

73 represents a visual display that may be presented on 
display 58 (e.g., a screen shot) and which may be created 
using programming techniques familiar to those of ordinary 
skill in the art. 

One set of manipulation elements 74 is a screen control 
group for governing the manner in which data fills the 
screen. Any data format may be viewed, such as images, 
waveforms, etc. A number index allows the operator to 
select the number of data representations that occupy the 
screen. FIG. 4 depicts twelve data representations in the 
form of radiology images 75 within UI page 73, but any 
number of representations may be selected. The operator 
may scroll to obtain subsequent representations in a series of 
such data in a file. For every representation, the portion that 
appears within the UI page 73 may be adjusted by a 
window/level control 102. Using the window/level control 
102, the size of the window may be changed and the 
horizontal level that appears on the display may be altered. 
Where the server 20 includes an element for fixing the 
default value for the window and level, the window/level 
control 102 may vary the setting from its default value. The 
server 20 optionally includes this window and/or level 
default element for setting default values in Hounds Field 
units. When the data is sent to a user unit, it appears on the 
user's display at the default window and level and control 
102 is used to adjust this value. 

Another screen control element is a cine control 104, 
which allows multiple images in a series to be stacked and 
viewed as fast moving figures layered one on top of the 
other. The cine control 104 is especially useful for echo in 
ultrasound data. By applying the cine control 104, an 
operator may drag a cursor, e.g., using a mouse or other 
cursor control device, over the image slices to repeatedly flip 
them in order or reverse order. To further control the display 
of data, a magnification control 106 provides for enlarge- 
ment of a region of interest, i.e., a selected portion (e.g., 
using a magnification boundary under user control) of the 
image. A zoom control 108 also is provided to increase the 
size of the entire screen. Conveniently, an operator my select 
a percentage of zoom, e.g., from 200% to 600%, inclusive, 
in any of a variety of increments, e.g., increments of 10%, 
20%, 25%, 50%, etc. 
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Another category of controls is a position group for 
changing the position of an image. Such position changers 
include a mirror control 110 for obtaining the mirror view of 
an image. By activating the mirror control 110 an image may 

5 be flipped over. The image may be rotated by a rotate control 
112, preferably by a quarter turn with each depression of the 
rotate control 112. In addition, where the server 20 includes 
an element for converting a 2-D image to 3-D volumes 
and/or surfaces, a 3-D control 114 may access the 3-D 

10 image. The server 20 optionally includes a 3-D volumetric 
rendering element to depict the internal makeup of a subject 
and/or surface rendering elements to show the 3-D version 
of the surface area of a subject. Through the use of these 3-D 
elements, a 2-D image captured by the server 20 may be 

15 converted and stored as a 3-D depiction of the image. This 
3-D image may then be e-mailed to a user unit. 

Still another set of manipulation elements is the inspec- 
tion tool set, which facilitates the examination of the images. 
A measurement control 116 provides linear distances 

20 between any given points on an image. In one embodiment, 
an operator is allowed to drag a cursor over the length of a 
portion of an image and the measurement control 116 
instantly determines the length so traced and displays such 
measurement to the user. Similarly, the measurement control 

25 116 may also determine the area of a selected region on the 
image. In a further embodiment, the measurement control 
116 may provide the angle of deviation between two 
selected vectors on the image. The operator may select a first 
vector and move the cursor, typically with a mouse, from the 

30 original vector to a second vector. In this manner, the angle 
of deviation between the first vector and second vector is 
presented. 

Locator line, control 118 is also an inspection tool for a 
scout view of DICOM MRI images or CT images to show 

35 where two images intersect within a study. Other inspection 
tools may provide the angle, area and/or volume of portions 
of an image. Furthermore a grid scale control 120 may be 
used to display a grid over the images, e.g., to be used as a 
measurement reference. Another control inverts the gray- 

40 scale of the image so that certain aspects of an image may 
become more visible. For example, by changing the contrast 
of an image, certain aspects thereof may stand out because 
different tissues are displayed with different levels of gray. 
An edge enhancement control 122 allows an operator to 

45 choose the degree of sharpness by digital enhancement of 
the images and smoothness of the edges of the images. 

Still another set of controls is for making annotations to 
the displayed image. Both an arrow control 124 and a 

5Q freehand control 126 may be provided for creating lines on 
an image. Such annotation may be erased by clicking clear 
control 128, or be hidden from the display, by manipulating 
hide control 130. A caption control allows for notes to be 
shown on the screen, especially next to lead lines pointing 

55 to certain aspects of the image. Other tools for annotation 
may be multi-media controls 132 for recording, stopping 
recording and/or playing back verbal notes. 

In one embodiment, the present system provides real time 
communication between correspondents. Where both corre- 

60 spondents access the same patient records at the same time, 
each correspondent may select, for example, by clicking a 
manipulation element, to view each other's annotations 
and/or to study the manipulations in real time. 
After viewing the image, the data may be saved to a local 

65 hard drive by save control 134, printed by print control 136 
and/or sent to another location via the server 20 by e-mail 
control 138, as described in detail above. As an added 



08/28/2003, EAST Version: 1.04.0000 



US 6,424,996 Bl 



15 



16 



feature, an HL7 report associated with images may be 
viewed by a report control. 

Further to the embodiment shown in FIG. 1, the present 
system anticipates the optional direct connection of medical 
modality 16 to user unit 50 through a modality inte rface 76 5 
(shown_in-FIG.-3).-An-application code in the^browser-Qj 
Enhancement module 54 all ows a vlrietyj)f modalities to be 
in'dil £ct xorjamu mcafo 60 . In this manner, 

tlsiu^ data 
sourres. 1^ be a 10 

££o2U£^ machine, 
Em^ltrasoimVVachine-or^^ "^B^i^L- 
inte£face_76_.on-the-user-unit>50-may-be-'a ^enaTJ^T^ 
um*versaTserial bus (USB)/or the like, depending on the 
particular connection between the modality 16 and the user 15 
unit 50. 

In addition, the enhancement module 54 provides for the 
direct control of the operations of a variety of medical 
modalities by a modality contrd„unitJ78,_Through this unit, 
the user unit 50 may control! a >.>0^^^^S^^j^^/{ 
operations, such as the setfangs durin||^^^BP^gdbn, ^ 
on/off, etc., depending, forjexample, oh theType oflnodality 
1 6 and"*p ^afjicu lar ~a™ i: — * : * ft c ^ * 



example, wh ere thel 



ptfaewisoE~unit SO. ^-For 
pigital earner a, the user 



d 25 



30 



35 



45 



unitmay-choose the ffames"of the-film~to~beniploaded"into 
the user unit 50 and then optionally clear the camera's 
storage area. In this manner, an operator may perform an 
examination with the browser enhancement module 54, 
through a modality 16 from a remote location. 

Referring again to FIG. 1, the second user unit 80 may be 
the recipient of e-mail from the server 20. The second user 
unit 80 includes an e-mail program that reassembles the 
messages so that the information can be read, for example, 
by using TCP protocol. The second user unit 80 may also 
download the browser and e-mail enhancement module 54 
in order to access any transferred images. Although FIG. 1 
shows only two user units, in variations of the transfer 
system 10, any number of user units may communicate with 
the server 20 in the same manner as user units 50 and 80. 
Preferably the number of user units is one to several thou- 
sand units and more usually about 1 to 100 units. 

There are many alternative features that may be added to 
information transfer system 10 to advance the functionality 
of the system. Having described the overall system, some 
optional aspects of the system will now be discussed. 

In one alternative/optional embodiment, the server 20 
automatically e-mails information to user units on scheduled 
intervals or whenever new data is received by the server. For 
example, the server 20 may have a list of users with their 50 
patient names. When the server 20 receives data relating to 
a particular patient, the server 20 identifies the appropriate 
users to receive the data regarding that particular patient. 
The server 20 may then automatically send the information 
to these users as it is received or at predetermined time 55 
intervals, for example by transferring to the user units 
associated with the appropriate users those user interfaces 
(e.g., Web pages) that have changed since the user's last 
visit. The data then resides locally on the user unit and may 
be viewed without first connecting to the server 20. The 
pages with data may also be viewed more quickly than if the 
pages were stored only at server 20, because the pages are 
read at high speed from the user unit's hard drive (or other 
long term storage device) rather than across slow wires of 
the Internet or another network. 

In another embodiment, server 20 alerts, such as by using 
alphanumeric pager, a practitioner with the status of incora- 



60 



65 



ing data. For example, the server 20 may notify the practi- 
tioner when new information regarding a particular patient, 
has arrived or when a study has been read by another 
practitioner or is waiting to be read. 

The server 20 may also integrate synchronous asymmetric 
replication (SAR) of data between the databases of multiple 
servers to create a distributed database architecture between 
servers. SAR may manage the distribution of information 
across a wide area network or between two or more servers. 
The SAR technology may also use complex rules and 
algorithms to regulate the sequence of data updates and to 
recover from interruption in communication links between 

servers in a geographically distributed network „ 

According to y et a fu rmejr^rrjbQoUment, the storage unit\ 
3.0 m the^erver 20 may include storage subunits for keeping < 
particular types of data. A clinical storage subunit may be 
provided for storing clinical medie^^ta and a parameter 
-storage subunit for storing pararhfte^meialcal data. The- 
^parameter-subunit-m ay include-a-he aderhavinginformatiorr 
relating the parameter data to the appropriate clinical data. 
Other storage subunits may exist to store various types of 
data forms. For example, particular subunits may be pro- 
vided for 3-D volume data, series data, annotation data and 
background data. However, the storage subunits are optional 
aspects of the present system. In some embodiments all data 
is stored in one central storage unit and not individual 
subunits. 

The server 20 may also have a protocol database, espe- 
cially in the clinical field, to build and retain guidelines 
which practitioners may follow in collecting the required 
information for a particular procedure, illness, patient 
complaint, etc. The guidelines may direct a practitioner to 
the correct processes in gathering any relevant information 
such as patient history, physical examinations, laboratory 
tests, procedures to facilitate a medically sound opinion, and 
the like. For example, a general practitioner desiring to 
consult with an orthopedic surgeon about persistent low 
back pain would select "orthopedic surgery" and then the 
name of the relevant hospital from a clinical protocol list. In 
this example, the protocols are listed by chief complaints. 
By selecting "low back pain," the practitioner is provided 
with the required tests, history, physical examination data to 
render a recommendation. These lists are available to a 
practitioner through e-mail from another practitioner or by 
uploading the information from the server 20. 

The protocols may be gathered from the server 20 through 
any number of sources. One way to derive the information 
is by converting existing libraries of clinical protocols from 
other servers. These other servers may update the present 
server by using SAR, or the like. In this manner, clinical 
protocols may be published to all servers in a network for 
use to any practitioner, especially where a generalist desires 
to generate a specialty consultation. 

Another source of clinical protocols is by a Web-based 
author interface allowing a practitioner to publish the pro- 
tocols to a server. The author interface is preferably built into 
the browser enhancement module 54, but may also be 
located on the server 20. The interface allows an operator to 
start from a generalized framework of the protocol to be 
created or to be edited and republished. A completed pro- 
tocol is published to the server and becomes the protocol of 
choice for that topic, when addressed to a particular 
practitioner, institution, the entire healthcare system, etc. 

The author interface allows practitioners to provide 
instant improvements to clinical protocols, publish new 
protocols, retire obsolete protocols, etc., without having to 
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intervene with current software programs. By internalizing 
the interface into the browser enhancement module, the 
application is not restricted by current browser technology 
limitations, such as the ability to create new fields in the 
clinical protocols. 

In alternative embodiments of the user unit 50, an e-mail 
server may be located in the user unit for viewing mail sent 
from the server 20 to the user unit 50. Furthermore, the user 
unit 50 may have an e-mail enhancement module which has 
attributes similar to those described above with respect to 
the browser enhancement module to enhance viewing of the 
user interface. Such an enhancement module is especially 
useful for MIME compliant e-mail servers. However, the 
e-mail component need not send instructions from the user 
unit 50 to the server 20, rather the e-mail component need 
only retrieve messages. 

Thus, the^present-information transfer system builds.uopn 

y t^on^j^t8Ss^ 

imeii^^ 

the^art^ 
The jj S&i^^ 
Vmu TOff^ ^ 

^^^^^^SmSmmm^^Mfmto another ^rre" (Smfen^ 
^TSnSBm^ the annotation 

and then respond with his own. 

Hie present invention has been described above in varied 
detail by reference to the particular embodiments and fig- 
ures. However, these specifics should not be construed as 
limitations on the scope of the invention, but merely as 
illustrations of some of the presently preferred embodi- 
ments. It is to be further understood that other modifications 30 
or substitutions may be made to the described information 
transfer system as well as methods of its use without 
departing from the broad scope of the invention. Therefore, 
the scope of the invention should be determined by the 
following claims and their legal equivalents. 35 

What is claimed is: 

1. A medical information transfer server comprising: 

A) a data interface for acquiring medical data in a 
multimedia format; 

B) a storage unit coupled to receive and store the multi- 40 
media medical data from the data interface; 

Q at least a portion of a user interface to allow for 
viewing the multimedia medical data; 

D) an assembly unit coupled to the user interface and the 
storage unit or to the data interface, the assembly unit 45 
to gather selected portions of the multimedia medical 
data to form an e-mail package in response to an 
instruction received from a remote first user unit; 

E) a processing unit coupled to the assembly unit or to the 
data interface and to encode and/or compress the mul- 
timedia medical data; and 

F) an e-mail server to send by e-mail the user interface 
and the e-mail package to a remote second user unit. 

2. The medical information transfer server of claim 1, 
wherein the multimedia medical data comprises image, 
overlay, 3-D volume, waveform, curve, video, and/or sound 
data, or any combination thereof. 

3. The medical information transfer server of claim 1, 
wherein the selected portions of the multimedia medical data 
are gathered from the storage unit. 

4. The medical information transfer server of claim 1, 
wherein the selected portions of the multimedia medical data 
include new data received from the data interface. 

5. The medical information transfer server of claim 1, 
wherein the selected portions of the multimedia medical data 
include new data received from the remote first user unit. 

6. The medical information transfer server of claim 1, 
wherein the user interface comprises a Web page. 
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7. The medical information transfer server of claim 1, 
wherein the processing unit is further to encrypt the multi- 
media medical data. 

8. The medical information transfer server of claim 1, 
wherein the processing unit is to compress the multimedia 
medical data using a progressive compression scheme prior 
to sending the e-mail package, 

9. The medical information transfer server of claim 1, 
wherein the processing unit is to compress the multimedia 
medical data using at least one of a wavelet, a motion 
wavelet, an MPEG or a motion JPEG compression scheme. 

10. The medical information transfer server of claim 1, 
wherein the processing unit is to compress the multimedia 
medical data by: 

(i) compressing the medical data to a default ratio; 

(ii) measuring the size of the compressed multimedia 
medical data; 

(iii) comparing the size of the compressed multimedia 
medical data to a required size; and 

(iv) repeating (i) through (iii) using the compressed 
medical data until the compressed multimedia medical 
data achieves the required size or smaller prior to 
sending the e-mail package. 

11. The medical information transfer system of claim 1, 
wherein the multimedia medical data includes clinical data 
and parameter data. 

12. The medical information transfer system of claim 11, 
wherein the data storage unit includes a clinical data storage 
subunit for storage of the clinical data and a parameter data 
storage subunit for storage of the parameter data. 

13. The medical information transfer system of claim 1, 
wherein the server further comprises a 3-D volumetric 
rendering element and 3-D surface rendering element to 
convert 2-D images into 3-D images. 

14. The medical information transfer system of claim 1, 
wherein the server further comprises a window and/or level 
element(s) for establishing window and/or level default 
values. 

15. The medical information transfer system of claim 1, 
wherein the server further comprises an automatic e-mail 
control to direct the e-mail server to automatically send new 
medical data to the remote first user unit at prescribed 
intervals. 

16. A medical information transfer unit comprising: 

A) a display for viewing a medical file on a user interface 
having at least one manipulation element for view 
control of the medical file,_and— : — . 

B) a %r^^rfor^ccffimW^ting with a serv er having 

rmultimedia" medical ^l@^lD^^^eUindudiiig_ a7 
-browser_enhancement modulerto:^^ ^ 

(i) request the m edical file from the server,--j 

(ii) decompress arW6r~decode~the-medical-file after 
receipt from the server; 

(iii) transfer the medical file to the display; and 

(iv) send instructions to the server to assemble and to 
e-mail selected multimedia medical data from the 
medical file and at least a portion of a user interface 
stored on the server to a remote user unit separate 
from the information transfer unit. 

17. The medical information transfer unit of claim 16, 
wherein the browser enhancement module comprises a 
plug-in or ActiveX control. 

18. The medical information transfer unit of claim 16, 
wherein the browser enhancement module is further to 
decrypt the medical file after receipt from the server. 

19. The medical information transfer unit of claim 16, 
wherein the medical file includes clinical data, parameter 
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data, series data, annotation data, observation data, 3-D 
volume data, and/or combinations thereof. 

20. The medical information transfer unit of claim 16, 
wherein the browser enhancement module is further to 
instruct the server to assemble the selected data with new 5 
data to form an package and to e-mail the package to the 
remote user unit. 

21. The medical information transfer unit of claim 20, 
wherein the transfer unit further comprises a modality 
interface for acquiring the new data. 

22. A medical information transfer system, comprising: 10 

A) a server storing multimedia medical data, the server 
comprising: 

i) a data interface for acquiring the multimedia medical 
data; 

ii) a storage unit coupled to receive and store the 15 
multimedia medical data from the data interface into 
medical files; 

iii) at least a portion of a user interface for viewing the 
multimedia medical data; 

iv) an assembly unit coupled to the user interface and 
the storage unit or to data interface, the assembly unit 20 
to gather selected portions of the multimedia medical 
data to form an e-mail package in response to 
instructions received from a first user unit; 

v) a processing unit coupled to the assembly unit or to 
the data interface and to encode and/or compress the 25 
multimedia medical data; and 

vi) an e-mail server to send by e-mail the at least 
portion of the user interface and the e-mail package 
to a second user unit. 

B) the first user unit comprising: 30 

i) a display for viewing at least a first one of the medical 
files using a user interface having at least one 
manipulation element for view control of the first 
medical file, and 

ii) a browser for communicating with the server, the 35 
browser including a browser enhancement module 
to: 

a) request the first medical file from the server; 

b) decompress and/or decode the first medical file; 

c) transfer the first medical file to the display; and 

d) send instructions to the server to assemble and to 40 
e-mail the selected portions of the multimedia 
medical data from the first medical file and the at 
least portion of the user interface to the second 
user unit. 

23. The medical information transfer system of claim 22, 45 
wherein the browser enhancement module is further to 
decrypt the first medical file. 

24. The medical information transfer system of claim 22, 
further comprising a medical modality for generating the 
multimedia medical data. 50 

25. The medical information transfer system of claim 24, 
wherein the medical modality comprises radiology equip- 
ment. 

26. The medical information transfer system of claim 22, 
further comprising at least two different types of medical 55 
modalities for generating the multimedia medical data. 

27. The medical information transfer system of claim 24, 
wherein the medical modality is communicatively coupled 
to the data interface for transmitting the multimedia medical 
data to the server. 

28. The medical information transfer system of claim 27, 60 
wherein the medical modality is communicatively coupled 

to the data interface through a dicomizer to convert raw 
multimedia medical data provided by the medical modality 
into multimedia medical data of a form compliant with the 
DICOM Standards. 65 

29. The medical information transfer system of claim 24, 
wherein the medical modality is communicatively coupled 



to the first user unit, and wherein the browser enhancement 
module is further to encode data received from the medical 
modality. 

30. The medical information transfer system of claim 22, 
wherein the browser enhancement module is further to 
encrypt the multimedia medical data, 

31. The information transfer system of claim 29, wherein 
the browser enhancement module is further configured to 
direct more than one operation of the medical modality. 

32. The medical information transfer system of claim 29, 
wherein the browser enhancement module is further to 
encrypt the data received from the medical modality. 

33. The medical information transfer system of claim 22, 
wherein the processing unit is to compress the multimedia 
medical data using at least one of a wavelet, a motion 
wavelet, an MPEG or a motion JPEG compression scheme. 

34. The medical information transfer system of claim 22, 
wherein the processing unit is to compress the multimedia 
medical data by: 

I) compressing the multimedia medical data to a default 
ratio; 

II) measuring the size of the compressed multimedia 
medical data; 

III) comparing the size of the compressed multimedia 
medical data to a required size; and 

IV) repeating (I) through (III) using the compressed 
multimedia medical data until the compressed multi- 
media medical data achieves the required size or 
smaller prior to sending the e-mail package. 

35. The medical information transfer system of claim 22, 
wherein the server further comprises an automatic e-mail 
control to direct the e-mail server to automatically send new 
multimedia medical data to the first user unit at prescribed 
intervals. 

36. The medical information transfer system of claim 35, 
wherein the server further comprises a mailing list of users 
designated to automatically receive the new multimedia 
medical data. 

37. A computer readable medium having stored therein a 
plurality of sequences of instructions, which, when executed 
by a processor, cause the processor through a browser to: 

A) request from a server a medical file for viewing with 
a user interface having at least one manipulation ele- 
ment for view control of the medical file, the server 
having stored therein medical files containing multi- 
media medical data; 

B) decompress and/or decode the medical file; 

C) transfer the medical file to a display; and 

D) e-mail instructions to the server to assemble and send 
by e-mail selected multimedia medical data from the 
medical file and at least a portion of the user interface 
from the server to a remote user unit separate from the 

T n £SiiM l l '< W lil I JUL I I I ii TT-^- 
38 flp^aSmpu le rtreao abrclm^liurnfofjel a-i m 37, wherein 

the mulumedirmedicll^iata isih the form of image, overlay, 

3-D volume, waveform, curve, video or sound data, or any 

combination thereof. 

39. The computer readable medium of claim 37, further 
including additional steps, which, when executed by the 
processor, cause the processor to decrypt the medical file. 

40. The computer readable medium of claim 37, wherein 
the decompressing is performed using a wavelet, a motion 
wavelet or a motion ^EG^ecomprejtsi ng sc heme. 

41. Cc^j^t | |(re!^ 

cause a processor iu; **** aaii ™«ws*MBE^^^SSSBSE 

A) request from a server a medical file viewable using a 
user interface having at least one manipulation element 
for view control of the medical file, the server having 
stored therein medical files containing multimedia 
medical data; 



08/28/2003, EAST Version: 1.04.0000 



US 6,424,996 Bl 



21 



22 



B) decompress and/or decode the medical file; 

C) transfer the medical file to a display; a ad 

D) e-mail instructions to the server to assemble and e-mail 
selected multimedia medical data from the medical file 
and at least a partial user interface from the server to a 
remote user unit separate from the processor 

42. The computer readable instructions of claim 41, 
wherein the multimedia medical data is in the form of image, 
overlay, 3-D volume, waveform, curve, video or sound data, 
or any combination thereof. 

43. A series of computer readable instructions embodied 
as data signals in a carrier wave, which when executed cause 
a processor through a browser to: 

A) request from a server a medical file viewable using a 
user interface having at least one manipulation element 
for view control of the medical file, the server having 
stored therein medical files containing multimedia 
medical data; 

B) decompress and/or decode the medical file; 

C) transfer the medical file to a display; and 

D) e-mail instructions to the server to assemble and e-mail 
selected multimedia medical data from the medical file 
and at least a partial user interface from the server to a 
remote user unit separate from the processor. 

44. The series of computer readable instructions of claim 
43, wherein the multimedia medical data is in the form of 
image, overlay, 3-D volume, waveform, curve, video or 
sound data, or any combination thereof. 

45. A method, comprising: 

A) receiving new medical data through a browser 
enhancement module; 

B) encoding and/or compressing the new medical data 
using the browser enhancement module; 

C) sending the new medical data to a server; and 

D) instructing the server to e-mail a medical file having 
the new medical data and selected stored multimedia 
medical data and at least a partial user interface to a 
second user unit. 

46. The method of claim 45, wherein the new medical 
data is received from a medical modality to be controlled 
using the browser enhancement module. 

47. The method of claim 45, further comprising encrypt- 
ing the new medical data after compressing the new medical 
data. 

48. The method of claim 45, wherein the new medical 
data is compressed using one of a wavelet, a motion wavelet 
or a motion JPEG compression scheme. 

49. The method of claim 45, wherein the new medical 
data is compressed using a progressive compression scheme 
wherein: 

A) the new medical data is compressed to provide com- 
pressed medical data; 

B) the size of the compressed medical data is compared to 
a required size; and 

C) steps A and B are repeated using the compressed 
medical data until the size of the compressed medical 
data is the required size or smaller. 

50. A series of computer readable instructions embodied 
as data signals in a carrier wave, which when executed cause 
a processor through a browser to perform the steps of: 

A) receiving new multimedia medical data from a medical 
modality; 

B) encoding the new multimedia medical data; 

C) compressing the new multimedia medical data; 

D) requesting from a server, a user interface having at 
least one manipulation element for viewing control of 
the new multimedia medical data; and 
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E) transferring the new multimedia medical data onto the 
user interface and sending the new multimedia medical 
data and user interface to the server. 

51. The series of computer readable instructions of claim 
50, further including instructions to cause the processor to 
direct the operation of the medical modality. 

52. The series of computer readable instructions of claim 
50, further including instructions to cause the processor to 
select stored medical data from the server and to direct the 
server to assemble the new multimedia medical data with the 
selected stored data and electronic mail a medical file 
including both the new multimedia medical data and the 
selected stored medical data to a remote user unit. 

53. The series of computer readable instructions of claim 
50, wherein the new multimedia medical data is in the form 
of image, overlay, 3-D volume, waveform, curve, video or 
sound data, or any combination thereof. 

54. The series of computer readable instructions of claim 
50, further including instructions which cause the processor 
to encrypt the new multimedia medical data after compress- 
ing the new multimedia medical data. 

55. The series of computer readable instructions of claim 
54, wherein the new multimedia medical data is compressed 
using one of a wavelet, a motion wavelet or a motion JPEG 
compression scheme. 

56. The series of computer readable instructions of claim 
50, wherein compressing the new multimedia medical data 
includes the steps of: 

A) compressing the new multimedia medical data to a 
default ratio to achieve compressed data; 

B) measuring the size of the compressed data; 

C) comparing the size of the compressed data to a 
required size; 

D) further compressing the compressed data if the size is 
greater than the required size; 

E) repeating steps B to D until the size of the compressed 
data is the required size or smaller. 

57. The series of computer readable instructions of claim 
50, wherein the at least one manipulation element on the 
user interface is a 3-D control and the server further has a 
3-D volumetric rendering element and 3-D surface rendering 
element for converting 2-D images into 3-D images. 

58. A server, comprising: 

A) a data interface for acquiring clinical multimedia 
medical data and parameter medical data; 

B) a clinical data s to rage unit coupled to the data 
interface and to receive the clinical multimedia medical 
data; 

C) a parameter data storage unit coupled to the data 
interface and to receive the parameter medical data; 

D) at least a portion of a user interface for viewing the 
clinical multimedia medical data; 

E) an assembly unit coupled to the user interface and the 
storage unit or to the data interface, the assembly unit 
to gather selected portions of the clinical multimedia 
medical data and the parameter medical data to form an 
e-mail package in response to instructions from a first 
user unit; 

F) a processing unit coupled to the assembly unit or to the 
data interface and to encode and/or compress the clini- 
cal multimedia medical data and the parameter medical 
data; and 

G) an e-mail server to send by e-mail the at least portion 
of user interface and the e-mail package to a second 
user unit. 
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